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SYSTEM AND METHOD OF DYNAMIC QOS NEGOTIATION IN NEXT GENERATION 

NETWORK 



Field of the Invention 

[0001] The present invention relates to network communication 
technology field, especially to a system and method of dynamic QoS 
negotiation in NGN. 



Background of the Invention 

[0002] One of the characteristics of Next Generation Network (NGN) 
is that the service layer is separated from the transport layer, and 
the transport layer is usually implemented based on packet switching 
technology and optical technology. At present, the TISPAN workgroup 
of Europe Telecom Standard Institute (ETSI) has established a 
functional framework of NGN, that supports Fixed-Mobile Convergence, 
on the basis of Third Generation IP Multimedia Subsystem (3G IMS) . 
As shown in Fig.l, the framework includes a service layer and an 
IP (Internet Protocol.) -based transport layer. 

[0003] As shown in Fig.l, the service layer is composed of Network 
Attachment Subsystem (NASS) , Resource and Admission Control 
Subsystem (RACS) , IP Multimedia Subsystem (IMS), PSTN/ISDN Emulation 
Subsystem (PES), other multimedia subsystems and applications, and 
common service components of those subsystems; the common service 
components include application servers, charging functions, user 
profile management, and security control, etc. 

[0004] Under the control of NASS and RACS, the transport layer 
provides IP connections between NGN terminals, which hides the 
transport techniques used in access and core networks below IP layer. 
Those subsystems can be distributed in the administrative domains 
.of network/service providers. 
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[0005] In an NGN environment, a critical component that provides 
support for end-to-end QoS control is RACS. The position of RACS in 
the overall framework of NGN and the interface relationship between 
the RACS and the external entities are shown in Fig. 2. The RACS needs 
to have interfaces with the transport layer, customer premise 
equipments (CPEs) , NASS, IMS, PES, other service subsystems, and 
RACSs in other networks. RACS provides admission control function; 
the admission control includes resource availability check based on 
the user profiles stored in NASS. Resource availability check means 
the admission control verifies whether the requested bandwidth is 
consistent with the subscribed bandwidth and the used bandwidth of 
each user. 

[0006] Due to diversity and multimedia feature of NGN services, how 
to implement QoS control on user service on the basis of IP-based 
transport layer has become an important task in NGN technical 
research. To this end, Internet Engineering Task Force (IETF) has 
put forward Integrated Service/Resource Reservation Protocol 
(IntServ/RSVP) , Differentiated Service (DiffServ) , and their policy 
control models and mechanisms. 

[0007] In IntServ/RSVP and its policy control model put forward by 
IETF and the Next Step IP Signaling (NSIS) draft that is being 
established, as shown in Fig. 3, users can transfer QoS parameters 
to the network through dedicated resource reservation signaling, to 
request for an expected QoS assurance level. Due to the fact that 
both RSVP and NSIS operate on the transport layer and pass through 
the same route and path as the data flow does, it is required that 
the CPEs support either RSVP or NSIS protocol, so as to send explicit 
QoS requests to the network. Such a QoS assurance method is 
inapplicable for users who can not initiate explicit QoS requests 
to the network. 
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[0008] In actual applications, i.e., in the current network 
environments, most of the CPEs (i.e. , users) do not support RSVP/NSIS 
protocol. In addition, even if new user terminals will support 
RSVP/NSIS protocol gradually, it is required to provide QoS 
requirements that can meet the users 1 traffic flow on the network 
side. However, the Policy Decision Function (PDF) performs admission 
control and gate control only based on user profile and the operator' s 
management policy rules without checking the availability of network 
resources based on resource status; and, consequently, assured QoS 
can not be provided in accordance with the actual conditions of the 
network. 

[0009] IETF has also put forward DiffServ and its policy control model, 
as shown in Fig. 4 . In detail, the user makes requests and negociations 
with the network on QoS, by using either of the following two methods: 
[0010] One method is: CPEs perform traffic classification, Dif f serv 
marking, policing, and shaping for the user packets; the network 
equipment trusts the Dif fServ marks in the user packets and performs 
Dif f serv forwarding . 

[0011] The other method is: users subscribe Service Level Agreement 
(SLA) with the network operator through an administrative approach; 
the SLA contains the required QoS parameters (e.g., bandwidth and 
Dif f Serv type) for user traffic. Network Management System (NMS) 
statically configures the QoS parameters requested by users onto edge 
devices of the network via policy control interface or network 
management interface. The edge devices perform traffic 
classification, Diffserv marking, policing, and shaping on the user 
packets in accordance with the QoS configuration; the core devices 
perform DiffServ forwarding in accordance with the DiffServ marks 
in the packets marked by the edge devices. 

[0012] In DiffServ and its policy control model put forward by IETF, 
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users perform QoS negotiation with the network in the management 
plane. In the network, the user QoS request is represented with the 
value of the Diffserv mark in the packet. Since a DiffServ mark has 
a length of only 3 bits, which can only reflect the relative 
requirements including QoS level and priority but can not transfer 
the user expected QoS parameters from end to end, including bandwidth, 
delay, jitter, and packet loss rate, etc.; therefore, the user 
traffic can only be provided with a relative QoS differentiation from 
the network. In addition, it is unable to implement QoS assurance 
for user service based on network resource availability as well. 
[0013] In conclusion, it can be seen that the IntServ/RSVP, the 
Diffserv, and their policy control models and mechanisms put forward 
by IETF can not provide QoS assurance in the data flow path between 
a User Network Interface (UNI) and another UNI (i.e., end-to-end) 
on the bearer layer in NGN, and thereby can not meet the requirements 
for service diversity, technique diversity, and terminal diversity 
in NGN. 

Summary of the Invention 

[0014] The object of the present invention is to provide a system 
and method of dynamic QoS negotiation in NGN, so as to enable an 
end-to-end QoS negotiation depending on the availability of the 
current network resources and thereby to improve transport network 
resource utility effectively. 

[0015] The object of the present invention is implemented with the 
following technical solution: 

[0016] In the present invention, there is provided a system of dynamic 
QoS negotiation in NGN, including: 

[0017] a Resource and Admission Control Subsystem (RACS) , adapted 
to obtain and process resource reservation requests required for 
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service transported in NGN, perform authentication and "make 
admission control decisions based on operation policy rules, user 
profile, and availability of transport resources, and send the 
admission control decision parameters to a concerned transport 
functional (TF) entity for execution, wherein the reservation 
•request contains QoS requirement parameters; 

[0018] the transport functional entities, adapted to ensure QoS of 
the media flow of the service transferred in NGN according to the 
admission control decision parameters. 

[0019] The system of dynamic QoS negotiation in NGN further includes: 
[0020] a service control functional (SCF) entity, adapted to 
communicate with user terminals, obtain the QoS requirement 
parameters required for the service requested by a user terminal by 
parsing service signaling or determine the QoS requirement 
parameters according to the service policies, and send the QoS 
requirement parameters to the RACS . 

[0021] The system of dynamic QoS negotiation in NGN further includes: 
[0022] a Network Attachment Subsystem (NASS) , adapted to manage and 
configure user access network, communicate with the RACS and the SCF 
entity, and provide the RACS and the SCF entity with user profile 
information associated with the service. 

[0023] The present invention also provides a method of dynamic QoS 
negotiation in NGN, including: 

[0024] A. obtaining by a RACS in NGN QoS requirement parameters 
required by a service; 

[0025] B. performing by the RACS admission control in accordance with 
the QoS requirement parameters and determining admission control 
decision parameters ; 

[0026] C. sending by the RACS the admission control decision 
parameters to a concerned transport functional (TF) entity at network 
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boundary, executing by the transport functional entity at network 
boundary the admission control decision parameters to process and 
transfer the media flow of the service accordingly. 
[0027] Wherein: 

[0028] the RACS obtains the QoS requirement parameters of the given 
service through a Service Control Functional (SCF) entity, a Network 
Attachment Subsystem (NASS) , the TF entity, or a Network Management 
System (NMS) . 

[0029] When the service includes a plurality of media flows, it is 
needed to determine the QoS requirement parameters for each of the 
media flows respectively. 

[0030] Before the step A, the method further includes a step E: 
[0031] initiating by a user terminal a service request to a SCF entity; 
[0032] when the service request does not carry the QoS requirement 
parameters of the service, determining by the SCF entity the type 
of the service in accordance with the service request, and 
determining the QoS requirement parameters required for the service 
in accordance with the service type; 

[0033] when the service request carries the QoS requirement 
parameters of the service, obtaining by the SCF entity the QoS 
requirement parameters of the service by parsing the service request. 
[0034] If the user terminal is a fixed terminal, the step E further 
includes : 

[0035] sending by the SCF entity a resource reservation request 
containing the QoS requirement parameters of the service to the RACS 
via a corresponding interface with the RACS. 

[0036] If the user terminal is a mobile terminal, the step E further 
includes : 

[0037] Sending by the SCF entity a resource authentication request 
containing the QoS requirement parameters of the service to the RACS 
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via a corresponding interface with the RACS; 

[0038] after the RACS authenticates successfully, notifying by the 
RACS the user terminal via the SCF entity; 

[0039] initiating by the user terminal a resource reservation request 
to the TF entities of the network via a path-coupling QoS signaling 
carryingQthe QoS requirement parameters of the service; handling by 
the TF entity at network boundary the QoS signaling and sending a 
resource reservation request containing the QoS requirement 
parameters of the service to the RACS via a corresponding interface 
with the RACS. 

[0040] If the token mechanism is used, after authenticating 
successfully, returning by the RACS an admission token to the user 
terminal via the SCF entity; carrying the admission token in a 
path-coupling QoS signaling and transferring the admission token to 
the RACS via a resource reservation request; checking by the RACS 
whether the resource reservation request has passed the 
authentication and searching for relevant information of the service 
in accordance with the admission token. 

[0041] The RACS determines the admission control decision parameters 
through the following steps: 

[0042] obtaining, by the RACS, the user profile information of the 
service and the policy rules information configured by the operator, 
making admission control decision for the QoS requirement parameters 
of the service based on the user profile information and the policy 
rules information, deciding whether to permit the media the flow of 
the service to enter into the network TF entity and to be treated 
with the requested QoS, and determining the admission control 
decision parameters. 

[0043] The RACS may also determine the admission control decision 
parameters through the following steps: 
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[0044] obtaining by the RACS the current status information of the 
transport resources in the network, making admission control 
decision for the QoS requirement parameters of the service based on 
above information, checking whether there are enough transport 
resources available in the network to meet the QoS requirement 
parameters of the service, and determining the admission control 
decision parameters . 

[0045] The admission control decision parameters include: 
[0046] Gate control, bandwidth allocation, Differentiated Service 
Code Point (DSCP) mark, and aggregation and adaptation control 
information . 

[0047] The QoS parameters include: 

[0048] bandwidth requirements for transferring the media flow of the 
service, as well as allowable delay, jitter, and packet loss rate. 
[0049] The method of dynamic QoS negotiation in NGN further includes: 
[0050] directly initiating by the user terminal a resource 
reservation request to the TF entities for the media flow of the 
service via a path-coupling dedicated QoS signaling; 
[0051] when the TF entity at network boundary receives the resource 
reservation request from the user terminal, sending by the entity 
a ■ resource reservation request carrying the QoS requirement 
parameters of the media flow of the user service to the RACS, and 
executing the step C. 

[0052] The method of dynamic QoS negotiation in NGN further includes: 
[0053] Configuring, by the NMS or the NASS, gate control, bandwidth 
allocation, DSCP marking control, and aggregation and adaptation 
control parameters onto the TF entity at network boundary via the 
RACS. 

[0054] It can be seen from the above technical solution provided in 
the present invention that the present invention provides end-to-end 

8 
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dynamic QoS request and negotiation processing procedures for 
different types of user terminals in NGN. Through the interaction 
between users and network as well as the interaction between network 
service layer and transport layer, the present invention is 
5 applicable to dynamic QoS negotiation processing for user terminals 
with different capabilities and for different business models 
required by the operators; furthermore, the present invention mainly 
utilizes the RACS in NGN to perform QoS negotiation processing, so 
as to implement an end-to-end QoS negotiation processing in 
10 accordance with the availability of current network resources in NGN, 
and thereby improve resource utilities with QoS treatment. Therefore, 
the present invention can effectively ensure the QoS of service 
transferred in NGN. 

15 Brief Description of the Drawings 

[0055] Fig.l is a structural schematic diagram of NGN; 

[0056] Fig. 2 is a schematic diagram of the external interface of RACS 

in NGN; 

[0057] Fig. 3 is a schematic diagram of IntServ and its policy control 
20 model; 

[0058] Fig. 4 is a schematic diagram of Dif f Serv and its policy control 
model; 

[0059] Fig. 5 to Fig. 9 are flow charts of an embodiment of the method 
described in the present invention. 

25 

Detailed Description of the Embodiments 

[0060] The key idea of the present invention is to utilize RACS to 
obtain QoS parameter information required for given service 
requested by CPEs and determine the corresponding admission control 
30 decision parameters based on the QoS parameter information and 
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resource availability information, and finally to utilize transport 
functional entity to execute the admission control decision 
parameters so as to process and transfer the media flow of the service 
accordingly, and thereby providing corresponding QoS assurance for 
services transferred in the network. 

[0061] First, in the present invention, in view of the diversity of 
access technologies and CPEs in NGN, it is required to investigate 
how user terminals with different intelligences and employing 
different access technologies can request and negotiate QoS with the 
network dynamically, with support of different business models taken 
into account. Second, since the various administrative domains in 
NGN may employ different QoS technologies and business models, it 
is required to consider how to support the QoS requirements of user 
traffic across different administrative domains and different QoS 
technology domains . 

[0062] To this end, first, the present invention provides a system 
of dynamic QoS negotiation in NGN. The structure of the system 
according to an embodiment of the present invention is shown in fig . 5, 
the system including: 

[0063] a Resource and Admission Control Subsystem (RACS) , which is 
adapted to obtain the QoS parameter information required by a service 
transferred in NGN, determine admission control decision parameters 
based on the QoS parameter information, and send the admission 
control decision parameters to concerned transport functional 
entities; 

[0064] the RACS obtains the QoS parameter information mainly via a 
service control functional entity; the RACS can also obtain the QoS 
parameter information via NASS, or via the transport functional 
entities; 

[0065] the transport functional entity, which is adapted to obtain 

10 
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admission control decision parameters sent from the RACS and execute 
the admission control decision parameters to implement QoS treatment 
forthe service transferred in NGN; 

[0066] The service control functional entity, which is adapted to 
communicate with a user terminal to obtain directly or indirectly 
the QoS parameter information required by the service requested by 
the user terminal and send the QoS parameter information to the RACS; 
[0067] when the user terminal is to develop a service, it has to 
initiate a service request to the service control functional entity 
first, and the request can carry the QoS parameter information 
required by the service; also, the service control functional entity 
can obtain the QoS parameter information of the service through 
negotiation between the user terminal and the opposite user or an 
application server; in addition, the service control functional 
entity can determine the corresponding QoS parameter information in 
accordance with the type of the service requested by the user 
terminal; 

[0068] a Network Attachment Subsystem (NASS) , which communicates 
with the RACS and the service control functional entities to provide 
them user profile information associated with the service. 
[0069] Based on the RACS and the interface relationship between the 
RACS and the external entities in NGN, the present invention provides 
a framework and a method to enable a user (i.e., CPE) to request and 
negotiate QoS with the network in NGN environment, and thereby, 
through the interaction between the user and the network as well as 
the interaction between the network service layer and the transport 
layer, to support QoS assurance for the services requested by user 
terminals with different capabilities and various business models. 
[0070] On the basis of above mentioned system, the present invention 
also provides a processing flow to enable a user to request and 

li 
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negotiate QoS with the network in NGN environment. As shown in Fig. 5, 
the service control functional (SCF) entity is responsible for 
functions of service session setup, control, and termination in the 
service subsystems, such as call session control function (CSCF) in 
IP Multimedia Subsystem. The present invention utilizes the 
interaction between CPE and SCF entity or transport functional (TF) 
entity to transfer QoS request and acknowledge information, and 
utilizes the RACS to process the interaction and negotiation on QoS 
support between SCF entity and TF entity, so as to implement an 
end-to-end QoS control and thereby meet the QoS request of the user. 
[0071] In the present invention, in order to implement resource 
usage-based charging, the SCF entity and the RACS need to interact 
with the TF entity, to collect resource usage information for 
charging for the user service. 

[0072] The present invention can support user terminals with 

different capabilities and various business models. 

[0073] User terminals can be classified into the following categories, 

regarding the different QoS negotiation capabilities: 

[0074] 1. User terminals unable to send explicit QoS requests by way 

of any signaling; 

[0075] 2. User terminals that support initiating resource 
reservation requests in dedicated QoS signaling, such as RSVP or 
NSIS; 

[0076] 3. User terminals that support negotiating QoS requirement 
in service signaling such as Session Initiation Protocol/Session 
Description Protocol (SIP/SDP) , etc.; 

[0077] 4. User terminals that support negotiating QoS with 
cooperation of service signaling and dedicated QoS signaling. 
[0078] The business models can be classified into three categories, 
regarding the QoS differentiation level: 

12 
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[0079] 1. QoS differentiation at application flow level: before a 
data flow of a service are started, the user needs to initiate a 
definite QoS request to the network for the data flow; the flow is 
treated in the network with the QoS parameters expected in the user 
QoS request; different data flows may be treated in the network at 
different QoS levels; 

[0080] 2. QoS differentiation at service type level: the user does 
not need to initiate a QoS request explicitly, while the QoS 
requirement for the service is implied by the service type; the 
network is responsible for determining the QoS level required by the 
traffic flow in accordance with the service type; the traffic flows 
of different types of services may be treated at different QoS levels; 
[0081] 3. QoS differentiation at user level: in accordance with the 
Service Level Agreement (SLA) signed between the user and the network 
operator, the user traffic flow will be treated at the QoS level 
expected in the SLA; the traffic flows of different users may be 
treated at different QoS levels. 

[0082] The prevent invention provides several QoS request and 
negotiation processing flows for user terminals with different QoS 
capabilities and different business models; though those processing 
flows are the same in the fundamental principle, they are different 
in implementation approach; the operator can choose the appropriate 
QoS request and negotiation processing flow, in accordance with the 
capability of the user terminal and the expected business model. 
[0083] First, the fundamental principle of the method described in 
the present invention is described hereunder: 

[0084] When the CPE is to develop a service requiring corresponding 
QoS assurance, the RACS in NGN obtains the corresponding QoS request 
information, performs authentication, and makes admission control 
decision for the QoS request information of the service. Since 

13 
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network status information such as network resource usage and network 
performance may be known in the RACS, the most reasonable QoS 
assurance can be determined for the corresponding service in 
accordance with the actual conditions of the network. 
[0085] Now, the method provided in the present invention is described, 
with reference to the accompanying drawings and preferred 
embodiments. The embodiments involve QoS request and negotiation 
processing flows implemented in accordance with the user terminals 
with different capabilities and business models, respectively. 
Hereunder the QoS request and negotiation processing flows will be 
described in several examples. 

[0086] 1. When the business model is QoS differentiation at service 
type level, the QoS requirement of a user service will be implied 
by the service type; in addition, the QoS request will be initiated 
by an SCF entity or a signaling gateway as an agent of the user in 
accordance with the user service type. 

[0087] A corresponding and specific QoS request and negotiation 
processing flow, i.e., a corresponding dynamic QoS negotiation 
processing flow as shown in Fig. 5, includes the following steps: 
[0088] step 51: the user initiates a service request, e.g. , call setup 
request, to the network; wherein, it is not required to contain the 
QoS requirement parameters of the current service explicitly in the 
service request; 

[0089] step 52: when the SCF entity or signaling gateway receives 
the user service request, it determines the QoS parameters required 
for the current service in accordance with the service type; the QoS 
parameters include: the bandwidth required for the current service 
as well as allowable delay, jitter, and packet loss rate, etc.; 
[0090] at the same time, the SCF entity or signaling gateway needs 
to send a QoS request (containing the QoS parameter information) for 

14 
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the current service to the RACS as an agent of the user; 
[0091] certainly, when a service includes a plurality of data flows 
at a time, it is required to determine the QoS parameters for each 
data flow and to send the corresponding QoS requests at the SCF entity 
or signaling gateway; 

[0092] step 53: when the RACS receives the QoS request, it performs 
authentication and makes admission control decision on the received 
QoS request in accordance with user profile, operator-specific 
policy rules, and resource availability, to determine the 
corresponding admission control decision parameters; 
[0093] in detail, when the RACS receives the QoS request, it is 
required to obtain the user profile and operator-specific policy 
rules, such as user identity information, SLA information, and the 
network configuration information corresponding to the user, etc.; 
in addition, RACS needs to check the availability of the current 
network resources, such as available bandwidth resource, occupied 
bandwidth resource, and network performance of the data flow path 
of the user in the network; after obtaining above information, the 
RACS can perform authentication and make admission control decision 
on the QoS request of the service in accordance with the obtained 
resource availability information; 

[0094] in addition, when RACS determines to permit the service to 
be transported in the network in accordance with the requested QoS 
parameters, it sends admission control decision parameter 
information such as gate control, bandwidth allocation, 
(Differentiation Service Code Point) DSCP mark, and aggregation and 
adaptation control commands etc. to the TF entity at the boundary 
of the network for traffic forwarding; 

[0095] the QoS request and negotiation flow provided in step 51 to 
step 53 is especially suitable for voice service and simple 

15 
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terminals . 

[0096] 2. When the user terminal supports initiating explicit QoS 
requests to the network service layer via service signaling such as 
SIP/SDP etc., the specific dynamic QoS negotiation processing flow 
as shown in Fig. 6 includes: 

[0097] first, the user terminal initiates a service request, e.g., 
call setup request, to the network; during the service setup process, 
the user terminal can negotiate the QoS parameters required for the 
current service with the opposite terminal or application server via 
service layer signaling (e.g., session description protocol of SIP 
or capability exchange protocol of H.323) ; the specific negotiation 
procedures may be identical to those in the prior art, and will not 
be defined in the present invention; 

[0098] if a service includes a plurality of data flows, the 
corresponding QoS parameters have to be negotiated for each of the 
data flows respectively. 

[0099] step 61: after the user terminal obtains the QoS parameters 
through negotiation, it sends a service request carrying the QoS 
parameters to the SCF entity; 

[0100] step 62 : when the SCF entity receives the user service request, 
it extracts the QoS parameters from the service request, and then 
forwards the QoS request to the RACS; 

[0101] step 63: based on user prof ile, operator-specific policy rules , 
and resource availability, the RACS performs authentication and 
makes admission control decision on the received QoS request; when 
the RACS determines to permit the service to be transferred in the 
network in accordance with the requested QoS parameters, it sends 
gate control, bandwidth allocation, DSCP marking control, 
aggregation and adaptation control commands, etc., to the TF entity 
at the boundary of the network for traffic forwarding. 

16 
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[0102] The QoS request and negotiation processing flow provided in 
step 61 to step 63 is suitable for multimedia services and terminals. 
[0103] 3. The User terminal initiates an explicit QoS request to the 
network service layer via a path-decoupling dedicated QoS signaling; 
the path-decoupling QoS signaling indicates that the QoS signaling 
path is independent to the user data flow path to which it provides 
service . 

[0104] In that case, the specific dynamic QoS negotiation processing 
flow as shown in Fig. 7 includes: 

[0105] step 71: the user initiates an explicit QoS request to the 
network service layer (i.e., SCF entity) via a path-decoupling 
dedicated QoS signaling for a data service at a time or a certain 
data service that requires QoS assurance; the QoS request contains 
the data traffic flow identification information, such as source and 
destination addresses, port, and protocol type of the data flow, 
etc. ; 

[0106] step 72: when the SCF entity receives the QoS request, it 
performs authentication for the data service in accordance with the 
data traffic flow identification information, and forwards the QoS 
request of the current service to the RACS after successful 
authentication; 

[0107] Step 73: based on user prof ile , operator-specific policy rules, 
and resource availability, the RACS performs authentication and make 
admission control decision on the received QoS request after it 
receives the QoS request message; if the RACS determines to permit 
the service to be transferred in the network in accordance with the 
requested QoS parameters, it sends gate control, bandwidth 
allocation, DSCP mar king control , aggregation and adaptation control 
commands, etc., to the TF entity at the boundary of the network for 
traffic forwarding . 

17 
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[0108] The QoS request and negotiation processing flow described in 
step 71 to step 73 is suitable for point-to-point or 
point-to-multipoint data services that require QoS assured paths. 
[0109] 4. When the user terminal performs a two-stage QoS request 
and negotiation via the cooperation of service signaling with 
path-coupling dedicated QoS signaling, the corresponding specific 
dynamic QoS negotiation processing flow as shown in Fig. 8 may be 
divided into two stages; the path-coupling QoS signaling indicates 
that the QoS signaling path is identical to the user data flow path 
to which it provides service; hereunder the two stages will be 
described: 

[0110] In the first stage: 

[0111] step 81: the user initiates a service request (e.g. , call setup 
request) to the network via the SCF entity, and during the service 
setup process, negotiates the QoS parameters required for current 
service with the opposite user or application server via SDP or 
capability exchange of H.323; 

[0112] if a service contains a plurality of data flows at a time, 
the corresponding QoS parameters need to be negotiated for each of 
the data flow; 

[0113] step 82: when the SCF entity receives the service request of 
the user, it extracts the QoS parameters to be negotiated from the 
request, and then sends a resource authentication request to the 
RACS; 

[0114] step 83: when the RACS receives the resource authentication 
request, it obtains the user profile and operator-specific policy 
rules, and determines availability of the current network resources; 
then, based on the user profile, operator-specific policy rules, and 
availability of current resources, the RACS performs authentication 
on the received QoS request; if the RACS determines to permit the 

18 
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service to be transported in the network in accordance with the 
negotiated QoS parameters, it sends an acknowledgement and an 
admission token (i.e., Token) to the SCF entity; 

[0115] step 84: when the SCF entity receives the admission token, 
it notifies the admission token to the corresponding user; 
[0116] It should be noted that the steps 82 to 84 in the first stage 
can be omitted in the case of a simplified procedure, and in this 
case, in the second stage, only the negotiated QoS requirement 
parameters are carried or processed, but the token is not needed to 
be carried or processed. 
[0117] In the second stage: 

[0118] step 85: the user terminal initiates a resource reservation 
request to the network transport layer via a path-coupling dedicated 
QoS signaling protocol (e.g. , RSVP or NSIS) , the request carrying the 
QoS requirement parameters negotiated in the service setup process 
and the admission token; 

[0119] step 86: when the TF entity at network boundary receives the 
resource reservation request, it sends the admission token and the 
resource reservation request to the RACS; 

[0120] step 87: when the RACS receives the QoS request, it performs 
admission control in accordance with the admission token in the 
request; and if the RACS determines to permit the service for the 
user to be transferred in the network in accordance with the 
negotiated QoS parameters, it sends a resource reservation response 
as well as gate control, bandwidth allocation, DSCP marking control, 
and aggregation and adaptation control commands, etc., to the TF 
entity at network boundary; 

[0121] when the TF entity at network boundary receives the resource 
reservation response, it forwards or terminates the resource 
reservation request of the user. 

19 
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[0122] The dynamic QoS negotiation processing flow described in step 
81 to step 87 is especially suitable for mobile multimedia services 
and terminals. 

[0123] In order to be compatible with the prior art, the present 
5 invention also provides the following two dynamic QoS negotiation 
processing flows. 

[0124] The first one: if a user terminal directly initiates a resource 
reservation request to the network transport layer via a dedicated 
path-coupling QoS signaling, the employed dynamic QoS negotiation 
10 process as shown in Fig. 9 includes: 

[0125] step 91: the user directly initiates the resource reservation 
request to the network transport layer (i.e., the TF entity at network 
boungdary) via a dedicated path-coupling QoS signaling such as RSVP 
or NSIS etc. ; 

15 [0126] step 92: when the TF entity at network boundary receives the 
resource reservation request, it sends a resource reservation 
request carrying the user resource reservation request information 
to the RACS; 

[0127] step 93: when the RACS receives the resource reservation 
20 request, it obtains the user prof ile, operator-specific policy rules, 
and availability of the current resources, and performs 
authentication and makes admission control decision on the received 
admission control request; if the RACS determines to permit the 
request, it sends a resource reservation response as well as gate 
25 control, bandwidth allocation, DSCP marking control, aggregation and 
adaptation control commands, etc., to the TF entity at network 
boundary; when the TF entity receives the resource reservation 
response, it forwards or terminates the resource reservation request 
of the user. 

30 [0128] The dynamic QoS negotiation processing flow described in step 
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91 to step 93 is a QoS parameter transfer approach adapted for the 
compatibility with the IntServ/RSVP and its policy control model put 
forward by IETF as described in the prior art. 

[0129] The second one: a dynamic QoS negotiation processing flow that 
is used when a user does not perform dynamic QoS negotiation with 
the network but subscribes a service level protocol (i.e. SLA) 
containing the QoS requirement parameters with the operator. The 
processing flow is detailed as: based on the QoS requirement 
parameters in the SLA subscribed by the user with the operator, the 
NMS or NASS configures the gate control, bandwidth allocation, DSCP 
marking control, and aggregation and adaptation control parameters 
onto the TF entity at network boundary via the RACS . That processing 
flow may be compatible with the QoS request and negotiation 
processing approach that is used in the Diffserv and its policy 
control model put forward by IETF, as described in the prior art. 
[0130] Though the present invention is described with above preferred 
embodiments, the protective scope of the present invention shall not 
be restricted by those embodiments. Any technician skilled in the 
field can be easily suggested modifications or alternations to the 
present invention with the technical scope disclosed in the present 
invention; any of such modifications or alternations shall be covered 
by the protected scope of the present invention as defined by the 
claims accompanied hereunder. 
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